home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941221-19950208 / 000298_news@columbia.edu_Fri Jan 27 20:38:27 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA23816
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 27 Jan 1995 20:29:40 -0500
  3. Received: by apakabar.cc.columbia.edu id AA26557
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 27 Jan 1995 20:29:39 -0500
  5. Newsgroups: comp.protocols.kermit.misc
  6. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!gatech!udel!news.mathworks.com!news.duke.edu!eff!news.umbc.edu!haven.umd.edu!purdue!mozo.cc.purdue.edu!news.physics.purdue.edu!london.physics.purdue.edu!korty
  7. From: korty@london.physics.purdue.edu (Andrew J. Korty)
  8. Subject: Re: File Transfers Fail Uploading but not Downloading!
  9. Message-Id: <D33004.1Dp@physics.purdue.edu>
  10. Sender: usenet@physics.purdue.edu (News Administration)
  11. Organization: Physics Department, Purdue University
  12. References: <D31EGK.Mo3@physics.purdue.edu> <3gb0hr$ki@apakabar.cc.columbia.edu>
  13. Date: Fri, 27 Jan 1995 20:38:27 GMT
  14. Lines: 40
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3gb0hr$ki@apakabar.cc.columbia.edu>,
  18. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  19.  
  20. >Yours are the classic symptoms of big buffers in the downstream direction,
  21. >tiny buffers in the upstream direction.  A common configuration, based on
  22. >the assumption that when one makes a dialup connection, the only upstream
  23. >traffic will be keystrokes (at most, 10 per second), but the downstream
  24. >traffic will be voluminous (the responses to your commands).
  25. >
  26. >Where are these "buffers"?  Probably in the terminal server.  And in your
  27. >case maybe we also have something going on with the modems.  Maybe your
  28. >DOV modems allocate higher bandwidth upstream than down.
  29. >
  30. >To cope with this situation, you can sometimes reconfigure the
  31. >communications equipment to be more symmetrical.  This requires digging
  32. >through the technical manuals for the devices involved.
  33.  
  34. ... and having access to that communications equipment.  I doubt PUCC
  35. would be to keen on such an extended level of customer service.
  36.  
  37. >But in any case, it is ESSENTIAL to institute the most effective possible
  38. >means of flow control at EVERY juncture along the communication path:
  39. >between your PC and the modem, between the answering modem and the
  40. >terminal server, and so on.  This should be "hardware" (RTS/CTS) flow
  41. >control if it is available.  In-band "software" flow control methods such
  42. >as Xon/Xoff do not work nearly as well.  Unfortunately RTS/CTS is not
  43. >always available.  For example, one popular terminal server model supports
  44. >RTS/CTS only in one direction (the downloading one, on the aforementioned
  45. >assumption) so uploads through these devices often run into trouble.
  46.  
  47. Well, I was using RTS/CTS between my PC and the modem, and no flow
  48. control between the machine and the terminal server.  I've tried
  49. changing these with no success.  I can't figure out what the modem
  50. pool uses to communicate with the terminal server, and I don't think I
  51. could change it if I needed to.
  52.  
  53. So, I guess I'm just hosed, unless other people start complaining
  54. about this as well ...
  55.  
  56. Andy